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I, Joachim Lohr, declare as follows: 

1. I currently hold the position of Senior Research Engineer at 
Panasonic R&D Center Germany GmbH, located in Langen, Germany, a company 
affiliated with the assignee of the above-identified application (the "Application"). I 
have been employed by Panasonic R&D Center Germany GmbH since June 2002. 

2. As evident from the attached CV, I have been involved in the 
telecommunications research since I commenced my studies in communications 
engineering at the Technical University of Darmstadt, Germany, in 1997 and obtained 
my Diploma degree 1 in communications engineering in 2003. I joined Panasonic R&D 
Center Germany GmbH in 2002. Since April 2003, I am working as a research engineer 
in the field of wireless standard development. As part of my responsibilities, I have 
been involved in the development and standardization of wireless communication 



1 The German Diploma degree is comparable to a Master degree in the U.S. 
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networks in the 3 r Generation Partnership Project (3 GPP) since then. In this 
connection, I have been actively participating in the development of the High Speed 
Uplink Packet Access (HSUPA) Work Item of the 3 GPP RAN 2 working group (WG2), 
to which the Application pertains, authored and co-authored more than 70 contributions 
to the standardization within the 3 GPP and attended numerous meetings of the 3 GPP 
since January 2004. Presently, I am leading Panasonic Cooperation's activities in the 
3 GPP in the 3 GPP RAN 2 working group for user plane standardization. I am also an 
inventor on a number of patents and patent applications (see enclosed list of patents and 
applications). 

3. I am one of the inventors of the inventions disclosed and claimed 
in the above-captioned application (hereafter referred to as the Application. I co- 
invented the subject matter of the Application with Dragan Petrovic and Eiko Seidel. It 
is fair to say that I have a profound knowledge not only of the QoS -aware scheduling 
mechanism described in the Application, but of the knowledge available in this field as 
of the time of filing the Application. 

4. I submit this Declaration as evidence of the differences of the 
presently claimed method for scheduling uplink transmissions over the references cited 
in this Office Action. I am familiar with the Application and have reviewed the 
outstanding final Office Action mailed on August 15, 2008, in addition to the 
documents cited by the Examiner in this Office Action. I provide my opinion on the 
invention as defined in the claims currently pending, taking into account the disclosure 
of the Application as originally filed, the general knowledge available in the art at the 
time the Application was filed, the level of skill of those of ordinary skill in the art and 
the subject matter from the below referenced prior art. 

5. The present invention relates to scheduling uplink transmissions 
of mobile terminals in a mobile communication system considering their Quality of 
Service (QoS) requirements. The presently claimed method is useful in terms of 



3/16 



allowing the QoS-aware scheduling of individual mobile terminals that multiplex flows 
having different QoS attributes onto a single dedicated uplink channel (see Application 
as published, e.g. section [00076]). 

The presently claimed method is based, in pertinent part, on the 
scheduler (for example, the base station) being informed by, for example, the Radio 
Network Controller (RNC) on the QoS attributes of the different flows of the mobile 
terminals which can be multiplexed to the dedicated uplink channel. A mobile terminal 
that desires to transmit data on the uplink sends a scheduling request to the scheduler to 
request an uplink resource. The scheduling request includes a flow identifier of one of 
the plural multiplexed flows the mobile terminal desires to transmit on the dedicated 
uplink channel. As the scheduler is aware of the QoS attributes for the different flows of 
the mobile terminals, the scheduler can associate the flow identifier in the scheduling 
request to the QoS attributes of the flow and bases its scheduling decision taking into 
account the QoS attributes of the flow. The scheduler may thus prioritize the allocation 
of uplink resources to the different mobile terminals that sent a scheduling request based 
on the QoS attributes associated to the flow identified in the respective scheduling 
requests (see Application as published, e.g., sections [0121], [0141], [0142], [0144] and 
[0147]). 

The presently claimed invention is therefore facilitating the scheduling of 
individual mobile terminals (i.e. on a per-mobile terminal basis ) while still allowing for 
QoS differentiation of mobile terminals (UEs) on a per-flows basis (see Application as 
published, e.g. sections [0117], [0139], [0145]. The scheduling of the mobile terminals 
on a per-mobile terminal basis is expressed in the presently claimed invention by 
referring to the "scheduling request [...] requests the allocation of an uplink resource for 
transmission on the dedicated uplink channel to the mobile terminal transmitting the 
respective scheduling request". The provision of a per-flow QoS differentiation is 
reflected in the presently claimed invention in the feature of "scheduling [. . .] based on 
the QoS attributes related to the flow identified by the identifier" that is comprised in 
the scheduling request. 

6. 3 GPP contribution Tdoc. R2-041519, "QoS and Scheduling 
Principles in HSUPA" by Nokia) proposes different concepts for uplink scheduling of 
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the E-DCH for discussion in the 3 GPP working group RAN 2 (see section 1), i.e. is 
related to the High Speed Uplink Packet Access (HSUPA) Work Item of the 3 GPP 
RAN 2 working group. Tdoc. R2-041519 focuses its discussion on the prioritization of 
Node B scheduling and channel selective scheduling. 

6.1 As a general comment, it should be noted that the 3 GPP 
contribution Tdoc. R2-041519 (Nokia) has been discussed in the 3 GPP RAN 2 working 
group in August 2004. At this point in time, the standardization and development of 
HSUPA and the related E-DCH transport channel was in a early stage. Tdoc. R2- 
041519 is therefore based on the assumption that the concepts used in High Speed 
Downlink Packet Access (HSDPA) are also applied to HSUPA. Accordingly, Tdoc. R2- 
041519 assumes that there is no multiplexing of MAC-d flows/priority queues provided 
- the multiplexing of multiple MAC-d flows into one TB (MAC-e PDU) on the 
transport channel, i.e. E-DCH, was agreed in December 2004, i.e., after the date of 
Tdoc. R2-041519, in meeting #45 of the 3 GPP RAN 2 working group. It should be 
further noted that the contribution is a general discussion document, which is not 
proposing any specific detailed solution but rather discussing several scheduling 
principles on a rather abstract level of detail. 

6.2 With respect to the prioritization of Node B scheduling, section 
2.1 of Tdoc. R2-041519 relates to four different options how the NodeB could 
differentiate the scheduling requests. 

6.2.1 According to the "first option" discussed in section 2.1, the 
Node B does not differentiate between different requests by the UEs but simply gives 
some portion of the available (E-DCH) capacity to the request received first. This kind 
of solution does not take account relative priorities between different services in any 
way and thus all radio bearers mapped to E-DCH would have same priority in the 
Node B scheduler and consequently does not provide any QoS differentiation of the 
services. 

Notably, unlike the present invention, there is no QoS differentiation in 
the scheduling decision of the Node B, i.e. the Node B does not consider any QoS 
attributes in the scheduling decision so that there is also no need to inform the Node B 
on the QoS attributes of the different flows. 
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Further, unlike the present invention, there is also no f low identifier 
provided in the scheduling requests (grant requests) of the UEs that could be used in 
scheduling the UEs by the Node B. 

6.2.2 According to the "second option" discussed in section 2.1, the 
Node B knows the relative priority of each UE compared to the other UEs . In this case 
the Node B scheduler could take this relative priority into account when performing the 
scheduling decision based on different rate grant requests from different UEs. Relative 
priorities only indicate that one UE is higher priority than another UE and should be 
served therefore first. However, relative priorities provide no information on other QoS 
attributes (like delay tolerance, power offset, etc.) which are necessary to efficiently 
schedule uplink resources, i.e. such that an efficient BLock Error Rate (BLER), which is 
the common measure for efficient radio interface utilization, can be realized. 

Notably, unlike the present invention, the Node B of Tdoc. R2-041519 is 
not aware of the QoS attributes of the individual flows (e.g. MAC-d flow, Radio Bearer) 
but knows only the relative priority of the individual UEs served by the Node B. Thus, 
unlike the presently claimed invention, in Tdoc. R2-041519, there is no differentiation 
on the per-flow level in the scheduling decision of the Node B . 

Unlike the presently claimed invention, this "second option" discussed in 
Tdoc. R2-041519 is also not suitable when multiplexing different flows on a single 
dedicated uplink channel (e.g. E-DCBO. As mentioned above, Tdoc. R2-041519 is 
assuming that no multiplexing of MAC-d flows is implemented. 

In addition, unlike the presently claimed invention, the "second option" 
discussed in section 2.1 of Tdoc. R2-041519 is also no identification of a flow by means 
of a flow identifier within the scheduling request (grant request). 

6.2.3 According to the "third option" discussed in section 2.1 of Tdoc. 
R2-041519, the Node B knows the relative priority between different MAC-d flows of 
different UEs . The Node B scheduler could take this relative priority of different MAC- 
d flows into account when performing the scheduling decision based on different rate 
grant requests from different UEs, if UEs are making grant request per MAC-d flows . 

Although "this solution would work fine if only one priority level is 
transmitted inside one MAC-d flow," however "if multiple priorities could be [are] 
transmitted inside on MAC-d flow by MAC-d multiplexing, [as] this solution would 
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face similar problems as the second option and could complicate the signalling between 
the UE and the Node B." This subject matter may imply the multiplexing of logical 
channels to individual MAC-d flows. Nevertheless, Tdoc. R2-041519 assumes that the 
MAC-d flows themselves are not multiplexed, but scheduling is performed per MAC-d 
flow (considering the relative priorities of the MAC-d flows for which rate grant 
requests have been sent), which implies that there is data of one single MAC-d flow 
transmitted in a given transmission time interval via the transport channel. This is unlike 
the presently claimed invention requiring the multiplexing of plural flows to a transport 
channel. 

Notably, unlike the present invention, in Tdoc. R2-041519 the Node B is 
not aware of the QoS attributes of the individual flows , but knows only the relative 
priority of the individual MAC-d flows served by the Node B. As outlined previously, 
relative priorities only indicate that one flow is higher priority than another flow and 
should be served therefore first. However, relative priorities provide no information on 
other QoS attributes (like delay tolerance, power offset, etc.) which are necessary to 
efficiently schedule uplink resources, i.e. such that an efficient BLock Error Rate 
(BLER), which is the common measure for efficient radio interface utilization, can be 
realized. 

Further, unlike the present invention, in Tdoc. R2-041519, there is also 
no flow identifier provided in the scheduling requests of the UEs that allows the Node B 
to identify the QoS attributes related to the flow that are to be considered in the 
scheduling decision. As mentioned above, the Node B is using a relative prioritization 
of MAC-d flows in its scheduling decision. To enable the Node B to perform the 
scheduling based on relative priorities, Tdoc. R2-041519 proposes to include an 
indication of the priority of the respective MAC-d flow to the rate grant requests (confer 
the 1 st and 2 nd sentence in the paragraph following the paragraph starting "The fourth 
option ..." in section 2.1). 

In Tdoc. R2-041519, the indication of the priority of the MAC-d flow 
within the grant request is thus not allowing the Node B to identify the MAC-d flow for 
which the grant request has been sent, so that the Node B cannot base its scheduling 
decision on its QoS attributes. 
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In addition, unlike the present invention, in Tdoc. R2-041519, there is no 
per-mobile terminal scheduling to request the allocation of an uplink resource for a 
transmission of multiplexed data of the plurality of flows, as the scheduling requests 
(grant request) are sent per-MAC-d flow (which could be referred to as "per-MAC-d 
flow scheduling"). 

6.2.4 According to the "fourth option" discussed in section 2. 1 of Tdoc. 
R2-041519, each MAC-d flow would have priority queues for different priorities in 
MAC-e of the UE and the Node B knows the relative priority of each priority queue. 
The Node B scheduler takes this relative priority of different priority queues flows into 
account when performing the scheduling decision based on different rate grant requests 
from different UEs, ifUEs are making grant request per priority queue. 

It should be noted that there appears a copy-and-paste error in Tdoc. R2- 
041519 in the second sentence of the section describing the "fourth option" reciting that 
"The Node B scheduler could take this relative priority of different MAC-d flows into 
account [...]". This passage should read "The Node B scheduler could take this relative 
priority of different priority queues into account [.. .]" in view of the preceding sentence 
and the following sentences all referring a distinction of grant requests for individual 
priority queues. 

The "fourth option" discussed in section 2.1 of Tdoc. R2-041519 does 
not set any restrictions on possible MAC-d multiplexing. However, this flexibility 
introduces extra complexity as priority queue distribution and multiple priority queues 
per MAC-d flow would be needed in UEs. The term "MAC-d multiplexing" should not 
be misinterpreted. The term does not refer to the multiplexing of MAC-d flows, but 
refers to the MAC-d entity providing a multiplexing function to multiplex different 
logical channels (that are input to the MAC-d entity) to a single MAC-d flow (that is 
output by the MAC-d entity). The "fourth option" discussed in section 2.1 of Tdoc. R2- 
041519 thus relates to a system in which there appear no restrictions on the multiplexing 
of logical channels (having different priorities) to a MAC-d flow in the MAC-d entity, 
but complexity is added due to requiring "de-multiplexing" data of a single MAC-d 
flow to distribute same to multiple priority queues according to their priority. 
Accordingly, on the network side, the reordering would be needed to be done separately 
for each priority, i.e. each priority would need separate reordering buffers, compared to 
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the "third option" where only one priority queue and reordering buffer is needed per 
MAC-d flow in UE and in S-RNC. If the re-ordering would be done on logical channel 
level, separate re-ordering distribution is not needed, as there would be one re-ordering 
queue per logical channel after MAC-e and MAC-d de-multiplexing. 

Similar to the 'third option" discussed in section 2.1 ? Tdoc. R2-041519 
again fails to disclose plural flows multiplexed to a transport channel . In the "fourth 
option" discussed in section 2.1 of Tdoc. R2-041519, scheduling is performed per 
priority queue, which implies that there is data of one single priority queue transmitted 
in a given transmission time interval via the transport channel. 

Notably, unlike the present invention, in Tdoc. R2-041519 the Node B is 
not aware of the QoS attributes of the individual flows, but knows only the relative 
priority of the individual priority queues served by the Node B. As previously 
mentioned, relative priorities only indicate that one flow is higher priority than another 
flow and should be served therefore first. However, relative priorities provide no 
information on other QoS attributes (like delay tolerance, power offset, etc.) which are 
necessary to efficiently schedule uplink resources, i.e. such that an efficient BLock 
Error Rate (BLER), which is the common measure for efficient radio interface 
utilization, can be realized. 

Further, unlike the present invention, in Tdoc. R2-041519, there is also 
no fl ow identifier provided in the scheduling requests of the UEs that allows the Node B 
to identify the QoS attributes related to the flow that are to be considered in the 
scheduling decision. As mentioned above, the Node B is using a relative prioritization 
of priority queues in its scheduling decision. To enable the Node B to perform the 
scheduling based on relative priorities, Tdoc. R2-041519 proposes to include an 
indication of the priority of the respective priority queue to the rate grant requests 
(confer the 1 st and 2 nd sentence in the paragraph following the paragraph starting "The 
fourth option ..." in section 2.1). 

The indication of the priority of the priority queue within the grant 
request is thus not allowing the Node B to identify the priority queue for which the grant 
request has been sent, so that the Node B cannot base its scheduling decision on its QoS 
attributes. 
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In the "fourth option" taught in Tdoc. R2-041519 the scheduling requests 
(grant requests) are sent per priority queue, unlike the present invention, where the 
scheduling requests are sent per mobile terminal to request the allocation of an uplink 
resource for a transmission of multiplexed data of the flows on the uplink transport 
channel. 



7. Kekki et al (US 2005/0073953 Al) relates to supporting DiffServ 
Code Points (DSCPs) commonly used in IP based network for IP-based services in a 
UMTS system (see sections [0012] and [0013]). In particular, Kekki et al disclose 
DSCPs supported by the Radio Network Layer (RNL) of a mobile communication 
system (see inter alia sections [0018] and [0019]). 

7.1 For understanding the subject matter of Kekki et al it is important 
to understand the meaning of the terms Radio Network Layer (RNL) and Transport 
Network Layer (TNL), the latter frequently occurring in this document. The figure 
(Fig. 10) below is showing the general protocol model within the UTRAN at the time of 
filing of Kekki et al 
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Figure 10: General Protocol Model for UTRAN Interfaces 2 



The Figure is taken from 3 GPP TS 25.401, "UTRAN overall description (Release 6)", version 6.2.0, 
December 2003 
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The Protocol Structure consists of two main layers, Radio Network 
Layer (RNL), and Transport Network Layer (TNL). All UTRAN related issues are 
visible only in the RNL, and the TNL represents standard transport technology that is 
selected to be used for UTRAN, but without any UTRAN specific requirements. 

The Control Plane (CP) on the RNL includes the Application Protocol, 
i.e. RANAP, RNSAP or NBAP, and the Signalling Bearer in the TNL for transporting 
the Application Protocol messages. Among other things, the Application Protocol is 
used for setting up bearers for (i.e. Radio Access Bearer or Radio Link) in the RNL. In 
the User Plane of the UTRAN architecture, there are the Data Stream(s) of the 
individual services, i.e. the flows in the Application, which are transported by so-called 
Data Bearers in the TNL. 

The next figure (Fig. 23) below, is illustrating the protocol model to 
highlight how data of the MAC-hs transport channel 3 is distributed via the Uu interface 
between UE and Node B and via the Iub interface between Node B and CRNC/SRNC 
for the case of HSDPA (providing the HS-DSCH transport channel). Please note that the 
following explanations are valid for other MAC layer configurations and transport 
channels as well. 
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Fig. 23: HS-DSCH Co-incident Controlling and Serving RNC 4 



3 Fig. 23 of 3 GPP TS 25.401 has been chosen, as Kekki et ah also refers to the example of HS-DSCH in 
section [0056]. 

4 The Figure is taken from 3 GPP TS 25.401, "UTRAN overall description (Release 6)", version 6.2.0, 
December 2003 
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As can be seen in the figure above, the Transport Network Layer (TNL) 
refers to the wired interface, Iub, between Node B and RNC (in some configurations to 
the wired interface, Iub, between Node B and RNC and the wired interface, Iur, between 
two RNCs) that is used to convey the data of the transport channels between UE and 
RNC. 

7.2 As shown in Fig. 4 ? Kekki et al disclose that the RNC signals 
either a DSCP or Transport Network Layer (TNL) QoS information to the Node Bs 
together with an indication (flag) indicating the type of information being sent (see 
sections [0039] to [0043]). Accordingly to Fig. 4, the TNL QoS information received in 
step 100 either contains the DSCP itself or a generic TNL-QoS that is converted into a 
DSCP. (see Fig. 4, step 112, sections [0046] and [0047]). 

Accordingly, the gist of the Kekki et al system resides in the 
introduction of signaling TNL QoS-related information from the RNC to the Node B 
that either comprises a DSCP or a generic TNL-QoS Code Point. Kekki et al mentions 
that the DSCP or generic TNL-QoS information may be conveyed by an Information 
Element (IE) of the Node B Application Part (NBAP) protocol during a Radio Link 
Setup and Radio Link Configuration (see section [0048]). This essentially means that 
upon setup of a Radio Link on the RNL between UE and RNC, QoS -related 
information for the Data Bearers in the TNL are provided to the Node B. The TNL-QoS 
information contains information of the QoS attributes for transporting data of the 
dedicated (transport) channels or shared (transport) channels via the Data Bearers (see 
Fig. 10) on the interface between Node B and RNC (see section [0058]). 

To summarize, Kekki et al provide the Node B with information on the 
QoS that should be provided on Transport Network Layer (TNLV i.e. the wired 
interface, Iub, between Node B and RNC . when receiving/forwarding the UE data on 
the transport channels from/to the RNC. This bears no relation to the presently claimed 
invention of scheduling uplink transmissions on the radio interface between UE and 
Node B taking into account QoS attributes of one of a plurality of flows to be 
multiplexed to the transport channel. 

The system of Kekki et al thus fails to relate to any of the features of the 
presently claimed invention. Although Kekki et al forwards TNL-QoS information 
from a RNC to a Node B, this is not the same thing as the feature of the presently 
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claimed invention of forwarding QoS attributes from a RNC to a Node B that relate to 
flows and are used in scheduling u plink resources to a UE to transmit data of flows 
multiplexed to an uplink transport channel . (Please note that the term "flow" in the 
presently claimed invention is not the same things as and cannot be interpreted as a 
"transport channel" to which the TNL-QoS information bear some relation in Kekki et 
aL, as the "flows" are multiplexed to a "uplink transport channel" in the presently 
claimed invention.) 

8. Schultz et aL disclose a "scheduling algorithm" of a UE or RNC 
within a UMTS system that is aiming to improve the Generalized Processor Sharing 
(GPS) as presented in the article "A Generalized Processor Sharing Approach to Flow 
Control in Integrated Services Networks: The Single Node Case", by Parekh et aL 
published in the DBEE-ACM transactions on networking, volume 1, no. 3 June 1993 (see 
page 12, lines 19-30). The disclosed "scheduling" approach aims to satisfy the 
guaranteed bit rate of highest priority channels as long as possible still providing a 
minimum level of service to all flows (see page 33, lines 8-12 and page 28, lines 19 to 
page 29, line 9). In this context, the term "flow" refers to a logical channel. In Schultz et 
aL QoS is known on a logical channel-basis, i.e. each logical channel has a QoS class 
(see page 23, lines 7-9) and also touches on the multiplexing of logical channels (see 
page 21, lines 20-24, page 23, lines 13-17 and page 29, lines 4-6). 

The term "scheduling" as used in Schultz et aL does not relate to the 
scheduling of uplink resources by a Node B in response to a scheduling request from a 
UE , as in the presently claimed invention. The term "scheduling" is used in Schultz et 
aL to describe the scheduling within a UE or RNC by means of an optimized algorithm 
for performing a GPS-based TFC selection (see e.g. page 17, lines 22-23; page 13, lines 
6-18), that is an algorithm that is distributing the physical air interface resources 
("predetermined transmission bandwidth") already granted to a UE to the individual 
services (logical channels) of the UE. 

As outlined in detail by Schultz et aL, the RRC entity determines the 
transport block size (TBS), i.e. the number of bits the MAC entity can transmit to the 
physical layer in a single transmission time interval (Til) (see page 10, lines 19-23), 
and configures the MAC entity with a so-called Transport Format Combination Set 
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(TFCS), which contains the allowed Transport Format Combinations (see page 11, lines 
6-9) that can be used for transmission to thereby determine the radio resource that can 
be used by for transmission within a TTI. The different logical channels that are 
multiplexed to the transport channels need to share the allocated radio resource for a 
given TTI. The TFC selection algorithm effectively determines how the radio resource 
is to be shared among the logical channels (see page 12, line 3 to page 13, line 18), i.e. 
how many bits of each logical channel are transmitted in each TTI to fill the given TBS. 

The gist of Schultz et al. resides in the optimized GPS-based TFC 
selection algorithm that schedules the data of the individual logical channels taking into 
account their QoS attributes (see page 21, lines 12-31). The GPS-based TFC selection 
algorithm of Schultz et al can be either used within the UE for uplink transmissions or 
by the RNC for downlink transmissions. 

Notably, unlike the present invention, Schultz et al. is not related to the 
scheduling of uplink resources by a base station. First of all, it should be noted that the 
GPS-based TFC selection algorithm of Schultz et al. is either used in the UE or the 
RNC (see page 21, lines 29-31), and not in the Node B (base station). Furthermore, the 
GPS-based TFC selection algorithm of Schultz et al is not used to schedule uplink 
resources in a Node B in response to scheduling requests by UEs. but to distribute 
already scheduled resources to the individual logical channels within the UE or RNC. 

Accordingly, Schultz et al is not related to any feature of the presently 
claimed invention except for multiplexing flows to a transport channel. 

9. I submit that the contents of 3 GPP contribution Tdoc. R2-041519, 
"QoS and Scheduling Principles in HSUPA" by Nokia, in particular the "fourth option" 
described in section 2.1 thereof, and the contents of Kekki et al and Schultz et al are 
very different from each other and the presently claimed invention, as follows. 

9.1. First, Tdoc. R2-041519, Kekki et al and Schultz et al. Kekki et 
al. relate to completely different technical fields. 

Tdoc. R2-041519 relates to the scheduling of uplink transmissions on a 
dedicated uplink channel in a mobile communication system taking into account 
the relative priorities of UEs, MAC-d flows or priority queues. 
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In contrast, Kekki et al relates to the signaling of TNL-QoS information 
from a RNC to a Node B, so as to configure TNL, i.e. the interface between 
Node B and RNC, according to a TNL-QoS, 

Further in contrast, Schultz et al relates to an optimized TFC selection 
based on GPS that is distributing an already granted radio resource. 

Taking the example of Fig. 23 above, this essentially means that Tdoc. 
R2-04 1519 and the Application relate to the scheduling procedure and related 
signaling between the MAC-d entities at UE and RNC , while Schultz et al 
relates to the operation of a single MAC-d entity in either UE or RNC . Finally, 
Kekki et al relates to the signaling of TNL QoS for the lub interface between 
the Node B and the RNC. 

9.2. Even if considering all three references, not one of the references 
relates to the following features of the presently claimed invention: 

a) provide QoS attributes of multiple flows to be multiplexed onto a 
single dedicated uplink channel by a mobile terminal to a base station (Node B) 
from a radio network controller (RNC), 

b) transmit a scheduling request from a mobile terminal (UE) to a 
base station (Node B) that includes a flow identifier identifying one of the 
plurality of flows to be multiplexed onto the single dedicated uplink channel by 
the mobile terminal (UE) and 

c) schedule by the base station (Node B) uplink resources for 
transmissions of mobile terminals (UEs) on the dedicated uplink channel based 
on the QoS attributes related to the flow identified by the identifier. 

10. In view of the above, these differences between the presently 
claimed invention and the three references discussed above would have made it 
necessary to carry out substantial adaptations that, in my opinion, would not have been 
within the level of skill of the ordinary worker at the time of the present invention, i.e., 
when the underlying European application no. 04023418.9 was filed. As further 
detailed below, I also believe that that a skilled worker at the time the Application was 
filed would have not have reasonably expected that carrying out the required 
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adaptations would have yielded a method allowing the scheduling of mobile terminals 
on a per-mobile terminal basis, while still providing a per-flow QoS differentiation. 

11. If considering to supplement the subject matter of the 3 GPP 
contribution Tdoc. R2-041519 with the subject matter of Kekki et al, the ordinarily 
skilled worker would, in my opinion, have used the subject matter of Kekki et al to 
configure the wired interface between the Node B and the RNC according to the TNL- 
QoS signaled, such that the uplink data transmitted, on the E-DCH transport channel 
according to Tdoc. R2-041519 from the UE to the Node B would be further forwarded 
from the Node B via a transport bearer to the RNC according to the configured TNL- 
QoS signaled from the RNC. 

Further considering the subject matter of Schultz et al, in my opinion, 
the ordinarily skilled worker would use the optimized GPS-based TFC selection 
procedure of Schultz et al. to schedule the uplink transmissions of different logical 
channels multiplexed to the E-DCH transport channel according to a rate grant provided 
by the Node B according to Tdoc. R2-041519. 

However, in my opinion, none of 3 GPP contribution Tdoc. R2-041519, 
Kekki et al, or Schultz et a I. have any subject matter that would have led the ordinarily 
skilled worker to any modifications to a system combining the subject matter of 3 GPP 
contribution Tdoc. R2-041519, Kekki et al, and Schultz et al so as to have the above- 
discussed features of the presently claimed invention. For example, such prior art lacks 
any disclosure of utilizing a per-mobile terminal scheduling approach and to include a 
flow identifier to the scheduling requests of the mobile terminals to allow for per-flow 
QoS differentiation in the scheduling decision, as defined in the claims. 

12. I hereby declare that all statements made herein are, to my own 
knowledge, true and that all statements made on information or belief are believed to be 
true; and further that these statements are made with the knowledge that willful false 
statements and the like are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code, and that such willful false statements may 
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jeopardize the validity of the captioned patent , application or any patent issued 
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